Florian Müllner [Sun, 6 Aug 2023 22:40:20 +0000 (00:40 +0200)]
cleanup: Remove spaces in object literals
We only adopted this style relatively recently, so there's a bit
more to adjust. Still, it's manageable and another step towards
getting rid of the legacy style.
Carlos Garnacho [Tue, 8 Aug 2023 22:26:52 +0000 (00:26 +0200)]
st: Mass update to ClutterActorClass event vmethod changes
These are now forwarded as ClutterEvent in order to remain accessible
on the Javascript side. This also means all ClutterActor implementations
in ST need to update to this change.
Carlos Garnacho [Tue, 8 Aug 2023 16:22:11 +0000 (18:22 +0200)]
js: Avoid Clutter.get_current_event() in Clutter.Actor event vfuncs
We sometimes obtained the current event through the general machinery
just so we could pass it along as a ClutterEvent instead of a specialized
subtype.
We now get that out of the box, so may avoid getting the current event
which is just a cast of the same current event we already have.
Carlos Garnacho [Tue, 8 Aug 2023 16:14:04 +0000 (18:14 +0200)]
js: Mass move to Clutter.Event getter methods in Clutter.Actor vfuncs
These traditionally got the various ClutterEvent subtype structs as their
argument, so it was not allowed to use ClutterEvent generic getter methods
in these vfuncs. These methods used direct access to struct fields instead.
This got spoiled with the move to make ClutterEvent opaque types, since
these are no longer public structs so GNOME Shell most silently failed to
fetch the expected values from event fields. But since they are not
ClutterEvents either, the getters could not be used on them.
Mutter is changing so that these vmethods all contain an alias to the
one and only Clutter.Event type, thus lifting those barriers, and making
it possible to use the ClutterEvent methods in these vfuncs.
Carlos Garnacho [Wed, 9 Aug 2023 09:47:28 +0000 (11:47 +0200)]
inputMethod: Check that there is an existing cursor location
Commit 17d9ec5788fb made the input method call update() more eagerly,
but also at times that it does not have a cursor position yet. Make
it bail out correctly in that situation.
Fixes: 17d9ec5788fb ("inputMethod: Keep Capabilite.FOCUS before context.focus_in/focus_out")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2876>
Carlos Garnacho [Tue, 8 Aug 2023 14:10:39 +0000 (16:10 +0200)]
ui/slider: Handle emulated scroll events through the Clutter.EventFlags
Emulated scroll events no longer get event.is_pointer_emulated() set to
True, instead this information is propagated through the Clutter.EventFlags
of the event.
Carlos Garnacho [Tue, 8 Aug 2023 14:08:36 +0000 (16:08 +0200)]
st: Handle emulated scroll events through the ClutterEventFlag
Emulated scroll events no longer get clutter_event_is_pointer_emulated()
set to TRUE, instead this information is propagated through the
ClutterEventFlags of the event.
Takao Fujiwara [Wed, 1 Mar 2023 14:42:18 +0000 (23:42 +0900)]
inputMethod: Keep Capabilite.FOCUS before context.focus_in/focus_out
If context.focus_out() is called *after* context.set_capabilities(0),
The FocusOut D-Bus method is ignored because of no FOCUS capability.
If context.focus_out() is called *before* context.set_capabilities(0),
The 0 capability is set to the next focused context and the
FocusIn D-Bus method is ignored because of no FOCUS capability.
So context.set_capabilities(0) should not be called.
Florian Müllner [Mon, 7 Aug 2023 15:13:48 +0000 (17:13 +0200)]
js: Port dbusUtils to ESM
The module is shared between the various D-Bus services and the
main gnome-shell process, so it was originally left out to allow
porting different bits at their own speed.
Now that everything has been ported to ESM, there is no reason
to not move that particular module as well.
Florian Müllner [Sat, 5 Aug 2023 19:12:55 +0000 (21:12 +0200)]
status/backlight: Sync checked on level changes
Since switching to property bindings/notifications, value changes
only happen on actual changes, so we cannot rely on them as the sole
source of updating the checked state.
Daniel van Vugt [Thu, 23 Mar 2023 09:51:46 +0000 (17:51 +0800)]
main: Correct the pointer value of strtab on riscv/mips architectures
Glibc defines `d_ptr`/`d_val` to be a relocated address on most
architectures, except for riscv and mips where it is just an offset from
the binary load address. So we need to convert `strtab` from an offset
into a pointer for riscv and mips.
Internally within glibc there is the `D_PTR` macro for doing this, which
relies on private data hidden in an ABI-unstable part of `link_map`. So
we can't use the same conditional logic as glibc does internally.
Our solution is to detect when `strtab` is unreasonably low (below the
address of our binary) and so it must be an unrelocated offset. In that
case we just do the relocation manually.
Florian Müllner [Wed, 2 Aug 2023 16:09:46 +0000 (18:09 +0200)]
status/backlight: Notify slider value changes
The custom setter used by the slider item isn't emitting change
notifications, so the property binding that uses it as source
never propagates the new value.
We have always defaults to an empty ornament, so that menu items
are always aligned, even when radio items are used.
However radio items are fairly rare, so most of the time we end
up with an extra margin with no purpose. The design team now
prefers radio items to only align with each other, so that regular
items get the expected margin.
We currently consider idle nodes as in use to avoid too fast state
changes and thus flickering of the indicator icon. However, the current
idle timeout is rather long and arguably confusing for users.
Thus switch to only consider running nodes as in use, but delay
disabling of the indicator by 500ms.
Florian Müllner [Tue, 13 Jun 2023 19:36:20 +0000 (21:36 +0200)]
status/backlight: Add new quick toggle
Settings no longer exposes a slider for the keyboard brightness,
leaving keyboard shortcuts as the only way of adjusting it.
This is good enough in most cases, because devices with keyboard
backlight usually include corresponding keys on their keyboard.
However for devices without those keys, it would be good for the
settings to be exposed somewhere again. Quick settings seems like
a more appropriate place than "proper" Settings, since it gives
quick access that doesn't require a major focus change.
extensions: Make ExtensionPreferences more flexible
Extensions must now export a class with a fillPreferencesWindow()
method in their prefs. That is less convenient for extensions
with simple preferences than the old buildPrefsWidget() hook, as
they must wrap their widget in page/group widgets.
Address this by adding a default fillPreferencesWindow() implementation
that calls a getPreferencesWidget() method and wraps it as necessary.
This is flexible enough to support different cases fairly conveniently,
from simple single-widget prefs over tweaking the window to complex
multi-page prefs:
```js
class SimplePreferences extends ExtensionPreferences {
getPreferencesWidget() {
return new SimplePrefsWidget();
}
}
class TinkerPreferences extends ExtensionPreferences {
getPreferencesWidget() {
return new SimplePrefsWidget();
}
If an extension provides the gettext domain in its metadata,
then we can simply set up translations from the constructor,
so do that for a bit more convenience.
All extension lookups now happen through the dedicated
Extension/ExtensionPreferences classes, so the shared
code no longer has to access the extensionManager.
Use the new defineTranslationFunctions() method from the previous
commit to create gettext functions for the module, instead of
re-exporting from the shared module.
It is now up to extension developers to use the more effective
The method can be used to define a set of gettext functions that
call the corresponding method of an extension.
Those functions are very similar to the gettext functions we are
exporting, except that:
- looking up the extension is delegated to the
Extension/Preferences class
- it is possible to avoid examining the stack
when called with `import.meta.url`
With convenience API like getSettings() now being provided by
the ExtensionObject subclass, extensions will need to access
their entry point more often.
Having to pass a pointer through the hierarchy can be annoying,
so add a static method that allows them to look it up:
extension-tool: Use Extension base class in templates
The Extension/Preferences classes are where we will focus for
future extension convenience API, so developers should be
encouraged to use them as entry points.
extensions: Add Extension/Preferences base classes
Extensions now must export a class that conforms to a particular
interface both for the actual extension as well as for prefs:
enable()/disable() methods for the former, fillPreferencesWindow()
for the latter.
This is quite similar to the previous method-based entry points,
but it also gives us a more structured way of providing convenience
API in form of base classes.
Do that in form of Extension and ExtensionPreferences classes on
top of a common ExtensionBase base class.
getSettings(), initTranslations() and the gettext wrappers are
now methods of the common base, while openPreferences() moves
to the Extension class.
extensionSystem: Include dir and path in data passed to extension
Extensions often need to set up additional resources from their
directory, like settings, translations or image assets.
So far extensions have used getCurrentExtension() to access the
shell's internal extension object which contains path and dir
properties. That's far from ideal, first because it requires
generating a stack to figure out the current extension, and
second because the internal object also contains state that
extensions shouldn't meddle with.
Just include those properties in the metadata we pass to the
extension constructor.
Pipewire allows us to easily track whether any cameras are in used by
checking the state of camera nodes. Add a simple camera monitor to the
shell, allowing us to show e.g. a status indicator.
Naturally the monitor is limited to apps using Pipewire for camera
access and thus subject to the same chicken-egg problem like the camera
portal - it could confuse users that apps may use the camera without
being noticed by the monitor. The hope and assumption here is that a
better shell integration might speed up adoption of the new camera APIs
Pipewire 0.3.49 is required for refcounted `pw_init()`/`pw_deinit()`.
projects / gnome-shell.git / log